Method and system for pooling computing server resources

ABSTRACT

A method and system for pooling computing resources is provided. In an embodiment a system comprises a plurality of quotation servers connected to a quotation engine. The quotation is also connected to a clearing server. The quotation engine receives data representing quotations from different servers. The quotation engine also receives data representing actual trades from the clearing server. The quotation engine is configured to perform operations on the quotations and the actual trades in a fashion that deletes certain quotations to reduce consumption of computing resources on the quotation engine and thereby increase efficiency of processing of the quotes to arrive at a final quotation. The system also relieves processing burden on the quotation servers by shifting the processing to the quotation engine.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.13/130,457, filed May 20, 2011, which is a US National Phase Applicationunder 35 USC 371 of PCT/CA2008/002053 filed on Nov. 21, 2008, thecontents all of which are incorporated herein by reference in theirentirety.

FIELD

The present specification relates generally to electronic tradingplatforms and more particularly relates to a computer-based method andsystem for pooling computing server resources.

BACKGROUND

Electronic trading is offered in many different markets, and is a wellknown means of matching orders to buy and sell items in the market.Matched orders can be then be electronically “executed” in order toimplement those matched orders. Electronic trading platforms necessarilyrequire technical resources in order to effect these electronic trades.Ongoing optimization of the hardware and software resources ofelectronic trading platforms has the technical effect of reducing loadson those hardware and software resources, and at the same time leadingto an overall improvement in quality of electronic trades, such qualitybeing indicated by speed (e.g. reduced network latency), efficiency(e.g. reduced processing resources on a central processing unit, reducedelectronic memory consumption), accuracy (e.g. the actual quoted valuefor a given item is correct) and the like.

Different types of electronic trades are characterized by different datarecord structures that represent the traded instrument. Such variationsin data record structures lead to unique technical structures andconfigurations that correspond to the different types of electronictrades. Furthermore, the network interconnections between serversinvolved in the electronic trading, and the configuration of thehardware and software processes on those electronic trading servers alsoimpacts the quality of different types of electronic trades.

One type of electronic trading is characterized by data records that arestructured to represent bonds. Bond data records are often maintained indifferent formats within different computing environments that are eachmaintained by different dealers. Electronic quotations associated withbond data records need to be updated on a periodic basis, typicallydaily, and made available to all dealers of bonds associated withcertain bond data records.

In certain current configurations, one example of which is theelectronic trading of bonds in Canada, computing environments maintainedby certain trading firms or dealers rely only on electronic trading dataassociated with that one computing environment, and do not interact withelectronic trading data associated with computing environmentsmaintained by other dealers. This leads to electronic quotations withinthe computing environment of one dealer that are heterogeneous inrelation to the electronic computing environments of other dealers. Inother configurations, computing environments of different dealers may benetworked in some fashion or another, so that electronic trading data ofall dealers can be examined to ascertain an electronic quote respectiveto a complete set of bond data records respective to a given bond asmaintained in computing environments associated with the participatingdealers. However, excessive computing resources can be consumed inexamining all bond data records respective to a given bond. Furthermore,excessive consumption of computing resources can also interfere withother networked computing resources that are dedicated to ultimatelyeffecting electronic trades based on timely and meaningful electronicquotes. It is therefore desirable to reduce the computing resourceburden associated with examining and processing bond data recordsrespective to a given bond in order to generate an electronic quote forthat bond.

SUMMARY

An aspect of the specification provides a system for pooling computingserver resources comprising a plurality of quotation servers. Each ofthe quotation servers are configured to maintain a dealer data recordcomprising a quotation for a bond. Each of the dealer data records aredifferent than each other dealer data record. The system also comprisesa clearing server configured to maintain a clearing data recordcomprising an actual traded value for the bond. The system alsocomprises a quotation engine connected to the quotation servers and theclearing server. The quotation engine is configured to receive thedealer data records and the clearing data record. The quotation engineis configured to perform a plurality of operations based on the dealerdata records and the actual traded value. The operations are configuredto successively delete one or more of said dealer data records. Thequotation engine is configured to perform a final price determinationbased on the dealer data records that survive the deletions.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a system for pooling computing server resources inaccordance with an embodiment.

FIG. 2 shows a flow-chart depicting a method for pooling computingserver resources in accordance with another embodiment.

FIG. 3 shows the system of FIG. 1 during exemplary performance of block205 from the method of FIG. 2.

FIG. 4 shows the system of FIG. 1 during exemplary performance of block210 from the method of FIG. 2.

FIG. 5 shows the system of FIG. 1 during exemplary performance of block255 from the method of FIG. 2.

FIG. 6 shows the system of FIG. 1 during exemplary alternativeperformance of block 255 from the method of FIG. 2.

FIG. 7 shows a method for pooling computing server resources inaccordance with another embodiment.

FIG. 8 shows a flow-chart depicting a method for pooling computingserver resources in accordance with another embodiment.

FIG. 9 shows a flow-chart depicting a method for pooling computingserver resources in accordance with another embodiment.

FIG. 10 shows a flow-chart depicting a method for determining a PriceAsk as part of optional output generation from other methods discussedherein.

DETAILED DESCRIPTION OF THE EMBODIMENTS

Referring now to FIG. 1, a system of pooled computing resources isindicated generally at 50. System 50 comprises a plurality of quotationservers 54-1, 54-2, 54-3 . . . 54-n (generically referred to herein as“server 54” and collectively as “servers 54”) all of which are connectedto a quotation engine 58 via any suitable network 62. System 50 alsocomprises a clearing server 66 that connects directly to quotationengine 58 and to network 62.

Each server 54 is typically a server or mainframe with a housingcontaining an arrangement of one or more central processing units,volatile memory (i.e. random access memory), persistent memory (i.e.hard disk devices) and a network interface (to allow each server 54 tocommunicate over network 62) all of which are interconnected by a bus.For example, each server 54 can be a Sun Fire V480 running a UNIXoperating system, from Sun Microsystems, Inc. of Palo Alto Calif.,having four central processing units each operating at about 900megahertz and having about sixteen gigabytes of random access memory.However, it is to be emphasized that this particular server is merelyexemplary, and an array of other types of computing environments forquotation engine 54 are within the scope of the invention, and in factit is expected that each server 54 would have a different computingenvironment. Each server can include a keyboard or mouse (or other inputdevices), a monitor (or other output device). Each server 54 istypically maintained as part of computing environment associated with adifferent dealer, and therefore each server 54 is typically different,in that different configurations of processors, memory, operatingsystems and software are implemented on each server 54. Each server 54is typically connected to other computing infrastructure associated withthe dealer, including trading screens, printers, file servers and thelike. As will be explained further below, each server 54 is configuredto maintain electronic data records representing quotations of differentbonds, and to forward those electronic data records to quotation engine58.

Quotation engine 58 is a server or a mainframe with a housing containingan arrangement of one or more central processing units, volatile memory(i.e. random access memory), persistent memory (i.e. hard disk devices)and a network interface (to communicate over network 62 with servers 54)all of which are interconnected by a bus. For example, quotation engine58 can be a Sun Fire V480 running a UNIX operating system, from SunMicrosystems, Inc. of Palo Alto Calif., having four central processingunits each operating at about 900 megahertz and having about sixteengigabytes of random access memory. However, it is to be emphasized thatthis particular server is merely exemplary, and an array of other typesof computing environments for quotation engine 58 are within the scopeof the invention. In a present embodiment, quotation engine 58 isconnected to a primary persistent storage device (not shown) thatmaintains persistent data associated with electronic data recordsreceived from servers 54 and from clearing server 66. As will beexplained further below, quotation engine 58 is configured to generatean electronic data record representing a final quotation for a givenbond.

Network 62 can be wired or wireless, or based on combinations thereof,and based on any type of known network architecture or platform, (e.g.the Internet or a wide area network) or combinations thereof. Generallynetwork 62 provides an infrastructure to interconnect engine 58, server66 and servers 54.

Clearing server 66 is also maintained on a server, mainframe or othercomputing environment and is associated with a broader electronicexchange for trading, and is configured to maintain electronic datarecords representing booked trades of bonds, and to forward those datarecords to quotation engine 58.

Referring now to FIG. 2, a method for pooling computing resources inaccordance with another embodiment of the invention is represented as aflow-chart and indicated generally at 200. In order to assist in theexplanation of the method, it will be assumed that method 200 isperformed using system 50. Furthermore, the following discussion ofmethod 200 will lead to further understanding of system 50 and itsvarious components. However, it is to be understood that system 50and/or method 200 can be varied, and need not work exactly as discussedherein in conjunction with each other, and that such variations arewithin the scope of the present invention.

Block 205 comprises receiving a data record representing a traded value.In system 50, block 205 is performed by quotation engine 58 whichreceives a data record Data Record DR-0 containing electronic datarepresenting a market value weighted price, yield, total volume traded,trade date, and settlement date, for a given bond issue. Block 205 isrepresented in FIG. 3, where traded-value data record Data Record DR-0is sent from clearing server 66 to quotation engine 58. Once received,data record Data Record DR-0 is stored in memory at quotation engine 58.As part of block 205, quotation engine 58 can be configured to applycorrections to data within data record Data Record DR-0 that is known tobe incorrect. A correction factor may be ascertained based on the datawithin data record Data Record DR-0. For example, if the price withindata record Data Record DR-0 is determined to be incorrect, it may becalculated based on the remaining data within data record Data RecordDR-0, if such data is correct. A further example of a correction factorinvolves examining trades that have been booked on clearing server 66with a price that includes the interest that has accrued but which hasnot been paid (“Accrued Interest”). (The normal expectation is thattrades have been booked clean, i.e. without Accrued Interest in thefinal price). Quotation engine 58 can be configured to also utilizeknown previous terms and conditions in a database that is configured toprovide a correction factor that recalculates the correct clean price byreversing out the Accrued Interest given the price date and settlementdate from the clearing system feed. Where such corrections cannot beapplied, because a correction factor is unknown or unascertainable, thendata record Data Record DR-0 is identified as being incorrect and method200 is halted, in favour of performing another process, such as method200 a or 200 b instead. (Method 200 a and method 200 b will be discussedfurther below). In some embodiments, quotation engine 58 may requestthat clearing server 66 send another copy of data record Data RecordDR-0, for example if it is determined that the previously received copyof data record Data Record DR-0 was corrupted.

Note that method 200 can be performed at any time, but is typicallyperformed within one half-hour after traded values for a given bondissue have been stored in a data record (such as data record Data RecordDR-0) on clearing server 66. Note that the half-hour time period is notfixed and is a non-limiting example. Generally, method 200 is commencedat a time that is substantially immediately after traded values for agiven bond issue have been stored in a data record on clearing server 66and are therefore available to quotation engine 58. Method 200 may alsobe performed at other times, however. In some embodiments, method 200may commence at any time during the period beginning substantiallyimmediately after traded values for a given bond issue have been storedin a data record such as data record DR-0 on clearing server 66, andending substantially immediately before the expiry of the traded valuesfor the given bond issue. Generally, traded values for a given bondissue expire at the start of the following trading period—typically, thefollowing business day—such that traded values for a given tradingperiod are used in the performance of method 200 during the presenttrading period only. However, it will be appreciated by those skilled inthe art that expiry times for traded values may be varied as desiredaccording to the context of the particular bond market. Also note thatmethod 200 can be performed for multiple bond issues, either as parallelprocesses within quotation engine 58, or serially or via a combinationof serial and parallel processes.

Also note that, in certain embodiments, quotation engine 58 isconfigured, as part of block 205, to normalize traded values for certainbonds within data record Data Record DR-0, in order to reduce oreliminate erroneous data and omit incorrectly booked trades. Thisvariation is discussed further below.

Block 210 comprises receiving quotes from trading firms or dealers. Insystem 50, block 210 is performed by quotation engine 58 which receivesdata records Data Record DR-1, Data Record DR-2, . . . Data Record DR-ncontaining electronic data representing quotes for a given bond issuefrom each respective quotation server 54. Block 205 is represented inFIG. 4, where quotation data records Data Record DR-1 . . . Data RecordDR-n are sent from quotation servers 54 to quotation engine 58.

In a present embodiment data records Data Record DR-1 . . . Data RecordDR-n are sent directly from quotation servers 54 to quotation engine 58.However, in a typical variant on this embodiment, data records DataRecord DR-1 . . . Data Record DR-n are posted by their respectivequotation servers 54 at different times to a quotation server database(not shown). In turn, data records Data Record DR-1 . . . Data RecordDR-n are then retrieved from the quotation server database (not shown)during performance of block 210.

Because of the heterogeneous nature of each quotation server 54, datarecords Data Record DR-1 . . . Data Record DR-n are typically inheterogeneous formats. Thus, as part of block 210 quotation engine 58can be configured to standardize data records Data Record DR-1 . . .Data Record DR-n into a common format. Furthermore, as part of block210, quotation engine 58 can be configured to apply corrections to datawithin each data record Data Record DR-1 . . . Data Record DR-n that isknown to be incorrect and where a known correction factor can beapplied. A correction factor may be ascertained based on the data withineach Data Record DR-1 . . . DR-n, for example by re-calculating aportion of the data known to be incorrect within a data record based onthe remaining data within the data record, if such remaining data iscorrect. Where such corrections cannot be applied, because a correctionfactor is unknown or unascertainable, then any data record Data RecordDR-1 . . . Data Record DR-n that is identified as being incorrect isomitted from further processing using method 200.

Block 215 comprises deleting data records from block 210 that containquotes that exceed a first predefined threshold of the traded valuewithin the data record from block 205. (Note that the term “delete” asused in this block and subsequent blocks can refer to completelydeleting from the storage of quotation engine 58, or can refer todeleting them within a block of storage that is dedicated to method 200,or to flagging them as “ignore” during subsequent processing of method200). In the present embodiment, the first predefined threshold value isreferred to as X %. The inventor determined that computing resourcesamongst servers 54 and engine 58 are efficiently utilized when X iswithin certain ranges. The inventor determined that X can be determinedby reviewing the variance of each individual bond issue that is pricedutilizing an historical analysis over a specific time period. A threemonth time period has been determined to be a suitable specific timeperiod, although it will be appreciated that other time periods may alsobe used and are intended to fall within the scope of the specification.Alternatively, X can be determined by reviewing the daily variance inpricing for the entire period of the issue's existence where the issuehas less than three months of pricing history. Using these techniques,the inventor determined that a first range for the value of X can bebetween about minus four and about plus four. Using these techniques,the inventor determined that a second range for the value of X can bebetween about minus twenty-five and about plus twenty-five. The inventorhas also determined that additional ranges for X can be set between thefirst range and the second range, and that the ranges need not beequally negative and positive. These ranges have been determined to leadto good utilization of computing resources of servers 54 and engine 58.

Block 220 comprises comparing the quotes within the data records thatsurvived the deletions from block 215. Block 225 comprises deleting datarecords from block 220 that exceed a second predefined threshold inrelation to each other. In the present embodiment, the second predefinedthreshold value is referred to as Y %. The inventor determined thatcomputing resources amongst servers 54 and engine 58 are efficientlyutilized when Y is within certain ranges. The inventor determined that Ycan be determined by examining historical data according to the type ofbond issue. Reviewing the daily variance in pricing history for a giventype of bond issue over a two-year time period has been determined to besuitable for this purpose, though it will be appreciated that other timeperiods may also be used. Using these techniques, the inventordetermined a first range for the value of Y can be between about minus0.750 and about plus 0.750. Using these techniques, the inventor alsodetermined that a second range for the value of Y can be between aboutminus 1.750 and about plus 1.750. The inventor has also determined thatadditional ranges can be set for Y between the first range and thesecond range, but those ranges are typically equally negative andpositive. These ranges have been determined to lead to good utilizationof computing resources of servers 54 and engine 58.

Block 230 comprises performing a mean and standard deviation operationon the quotes stored in the data records that survived deletion at block225. Block 235 comprises deleting firm quotes from block 230 that exceeda third predefined threshold of the standard deviation operation fromblock 225. In the present embodiment, the third predefined thresholdvalue is referred to as Z %. The inventor determined that a range forthe value of Z of between about minus one and plus one leads to goodutilization of the computing resources of servers 54 and engine 58. Theelection to utilize one standard deviation from the mean was based onthe fact that for data that is “normally distributed” it is expect thatabout 68.27% of the data will be within one standard deviation of themean. One standard deviation from mean is recognized in the art as acommon standard used that still provides a reasonable data set inrelation to the mean for this purpose.

Block 240 comprises determining if any of the firm quotes survived thedeletion from block 235. If a “no” determination is made at block 240,then at block 250 an exception handling routine is invoked at engine 58.Such an exception handling routine 58 can comprise performing anydesired alternative process for determining a final price for theparticular bond issue, or an error message indicating that final pricefor the particular bond issue was not ascertainable. For example, afinal price may be set as the average of prices within surviving datarecords from an earlier block, such as block 215. As another examplemethod 200 a or method 200 b, discussed further below, may be invoked.If a “yes” determination is made at block 240, then at block 245 a finalprice is determined using the quotes stored in the data records thatsurvived deletion block 235. In a present embodiment the final price forthe bond issue is calculated by determining the mean of the quotesstored in the data records that survived deletion at block 235. Thefinal price determined at block 245 is generated. In a presentembodiment the final price is incorporated into a data record DRn+1.

Block 255 comprises generating one or more output data records forsubsequent processing. Engine 58 can be configured at block 255 toreturn data record DRn+1 to a portion of, or all of the quotationservers 54. In a present embodiment, engine 58 is configured to returndata record DRn+1 only to quotations servers 54 that submitted datarecords at block 210 that survived deletion at block 225. Thisconfiguration is designed to further improve efficient use of quotationservers 54 and engine 58 to discourage repeated submission (onsubsequent performances of method 200) from the same quotation servers54 of data records at block 210. (Note that since servers 54 and engine58 may cooperate via method 200 for multiple bond issues, it iscontemplated that a given server 54 may be properly participating inmethod 200 for certain bond issues, but presenting inaccurate datarecords for method 200 for other bond issues).

In a present embodiment block 255 comprises returning data record DRn+1to at least a portion of the quotation servers 54. Exemplary performanceof block 255 is represented in FIG. 5 as a data record DRn+1, whichcontains the final price of the bond issue as determined at block 240,and which is returned to quotation servers 54-1, 54-2 and 54-n, but isnot returned to quotation server 54-3, which takes into the account theexample that quotation server 54-3 had submitted data record DR-3 whichdid not survive deletion at block 225. FIG. 6 shows an alternative tothe performance of block 255 shown in FIG. 5, wherein in addition toreturning data record DRn+1 to quotation servers 54-1, 54-2 and 54-n, anexception report ER is also sent to quotation server 54-3 indicating toquotation server 54-3 that data record DR-3 did not survive deletion atblock 225. Exception report ER can then be used by quotation server 54-3to update processes within quotation server 54-3 so that erroneous datarecords for that bond issue are not sent again, and thereby furtherreduce processing resource wastage on engine 58.

The returned data to quotation servers 54 can then be fed back intoautomated trading processes (either hosted on server 54 itself oranother server) that automatically lead to electronic instructionsrepresenting orders to buy or sell that particular bond. By relievingprocessing stresses on each quotation server 54, computing resources canbe directed to the automated trading processes and thereby reducelatency associated with such automated trading processes.

Referring now to FIG. 7, a method for pooling computing resources inaccordance with another embodiment of the invention is represented as aflow-chart and indicated generally at 300. In order to assist in theexplanation of the method, it will be assumed that method 300 isperformed using system 50. Furthermore, the following discussion ofmethod 300 will lead to further understanding of system 50 and itsvarious components. However, it is to be understood that system 50and/or method 300 can be varied, and need not work exactly as discussedherein in conjunction with each other, and that such variations arewithin the scope of the present invention.

Block 305 comprises determining if new data records that store actualtrades are available. The type of data records contemplated at block 305is the same type of data records (i.e. those stored or made availablefrom clearing server 66) as contemplated at block 205 of method 200.“New” means data records that have changed or added since the mostrecent performance of method 200. A “yes” determination is reached atblock 305 if new data records that store actual trades are availablesince the most recent performance of method 200, in which case block 310is reached, at which point method 200 is invoked as before. A “no”determination is reached if new data records that store actual tradesare not available, in which case block 315 is reached.

Block 315 comprises determining if lead dealer data records areavailable. A “yes” is satisfied at this block if a data recordcontaining a quote for a particular bond issue is available from the oneof the quotation servers 54 that is respective to the dealer thatactually initially issued the particular bond (i.e., the “lead dealer”)in relation to which method 300 is being performed. Thus, in order toeffect block 315, quotation engine 58 is configured to maintain adatabase that identifies which quotation server 54 is respective to thelead dealer for each bond issue that is processed by quotation engine54. This database is used to perform block 315.

A “yes” determination is therefore reached at block 315 if a data recordcontaining a quote for a particular bond issue is available from the oneof the quotation servers 54 that is respective to the lead dealer, inwhich case block 320 is reached, at which point a method 200 a isinvoked. Method 200 a is discussed further below. Where a “no”determination is made at block 315, block 325 is reached, at which pointa method 200 b is invoked. Method 200 b is discussed further below.

Method 200 a is illustrated as a flow-chart in FIG. 8. Method 200 a is avariant on method 200 and thus like blocks bear like references exceptin method 200 a references are followed by the suffix “a”. Of note isthat in method 200 a, block 205 is omitted and replaced with block 207a. Block 207 a comprises receiving a data record from a quotation serverrespective to the lead dealer that includes a quote for the bond issue.Also of note is that block 210 is omitted and replaced with block 209 a.Block 209 a comprises receiving data records from the remainingquotation servers 54 (i.e. all quotation servers 54 except for thequotation server 54 from block 207 a) respective to dealers other thanthe lead dealer's quotation server. The data records at block 209 acontaining a quote for the bond issue respective to those quotationservers 54. Otherwise, method 200 a performs substantially the in samemanner as method 200, though with appropriate adjustment according tothe context of the data received at blocks 207 a and 209 a.

Method 200 b is illustrated in flow-chart in FIG. 9. Method 200 b is avariant on method 200 and thus like blocks bear like references exceptin method 200 b references are followed by the suffix “b”. Of note isthat in method 200 b, block 205 is omitted and replaced with block 208b. Block 208 b comprises determining whether method 200, method 200 a ormethod 200 b had been performed most recently, and receiving the finalprice from block 245, block 245 a or block 245 b depending on which ofthose three blocks had been performed most recently. Otherwise, method200 b performs substantially the in same manner as method 200, thoughwith appropriate adjustment according to the context of the datareceived at block 200 b.

While the foregoing describes certain embodiments and examples, itshould be understood that these are non-limiting, and that variations,subsets, and combinations are within the scope of the invention. Forexample, as described above in relation to in system 50, block 205 wasperformed by quotation engine 58 which receives a data recordrepresenting a market value weighted price, yield, total volume traded,trade date, and settlement date, for a given bond issue. However, asnoted above, quotation engine 58 is configured, as part of block 205, toreceive a plurality of traded values for a given bond issue as part ofdata record Data Record DR-0, and to assess and correct those tradedvalues where necessary, in order to reduce or eliminate erroneous dataand omit incorrectly booked trades. In this variation Quotation engine58 is configured to reverse engineer the data stored within data recordData Record DR-0 to determine such a normalized price. Such a normalizedprice reflects the price at which the trade actually occurred, ratherthan a non-normalized price which may be actually stored within datarecord Data Record DR-0, and which reflects the actual price of the bondplus accrued value of the bond, as provided by clearing server 66.Quotation engine 58 is also configured to omit bond trade values in datarecord Data Record DR-0 that reflect repurchase agreements that havebeen incorrectly stored in data record Data Record DR-0 as clienttrades. The surviving, corrected actual trade values within data recordData Record DR-0 are aggregated to provide a market value weightedprice, yield and total volume traded for each issue. In someembodiments, for example where pricing is to be determining forinstitutional bond trading, trades having less than about 500,000 facevalue are also omitted by quotation engine 58. It will be appreciated bythose skilled in the art, however, that smaller trades may also be usedin other embodiments.

The inventor has conducted tests using the foregoing. Results of certainof those tests in relation to performances of various methods arediscussed below. A first test was run with a first bond referred toherein as Bond 1 using method 200, as discussed below.

TABLE I-1 Exemplary Data Record DR-0 Block 205 of Method 200 EffectiveBond Issue CUSIP Maturity Maturity Traded Traded Traded Orig Prev/CDSNumber Name (Identifier) Coupon Date Date Date Amount Trades Price PricePrice Bond 1 Telus 87971MAG8 4.95 Mar. 15, Mar. 15, Oct. 20, 70000 1.0081.25 89.61 81.25 Corp. 2017 2017 2008

Table I-1 shows an exemplary data record DR-0 that can be received atblock 205. The bottom row in Table I-1 represents a single performanceof method 200. In Table I-1, Bond Number refers to a number assigned inTable I-1 for convenience in this specification for ease of reference ofto this particular example. Issue Name refers to the legal entity (e.g.Corporation, government) that issued the bond. CUSIP means Committee onUniform Security Identification Procedures and is a unique identifierused in the securities industry used to uniquely identify a particularbond. Coupon refers to the interest rate associated with thecorresponding CUSIP identifier. Maturity Date refers to the date onwhich the bond is redeemable, and effective maturity date refers to themeasure of a bond's maturity which takes into consideration thepossibility that the issuer may call the bond before its maturity date.Traded Date refers to the date of the trade. In this example the date ofOct. 20, 2008 is given, and thus a suitable time for method 200 to havebeen performed is on Oct. 20, 2008 shortly after the data in Table I-1became available. Traded Amount indicates the volume of the trade.Trades indicates the number of trades that were required to effect thetraded amount. Traded Price indicates the actual traded price asdiscussed above in relation to block 205, and which is extracted fromdata record DR-0 for use in subsequent steps of method 200. Originalprice indicates the closing price for the last previous business dayheld in the database (as built by this model on the previous businessday). Previous/CDS Price indicates the most recent previous traded pricefor this bond issue as obtained from a clearing server 66 maintained,for example, by a clearing house entity such as Clearing and DepositoryServices Inc. (CDS) in Canada.

TABLE II-1 Quoted Price Portion of Data Records for Bonds Block 210 ofMethod 200 Server Server Server Server Server Server Server ServerServer Server Server 54-1 54-2 54-3 54-4 54-5 54-6 54-7 54-8 54-9 54-1054-11 Data Data Data Data Data Data Data Data Data Data Data Bond RecordRecord Record Record Record Record Record Record Record Record RecordNumber DR-1 DR-2 DR-3 DR-4 DR-5 DR-6 DR-7 DR-8 DR-9 DR-10 DR-11 Bond 188.79 90.17 89.59 77.54 92.66 86.07121 88.08 90.04 81.90 89.81 93.84

Table II-1 shows the quoted price portion of data records DR-1 . . .DR-11 received from eleven quotation servers 54 (i.e. where n=11) aspart of performance of block 210. Thus each cell in Table II-1 reflectsa quoted price in the form of raw data as discussed above in relation toblock 210. The data has already undergone relevant assessment andcorrection operations as discussed above.

TABLE III-1 Data Records Surviving Deletion Block 215 Server ServerServer Server Server Server Server Server Server Server Server 54-1 54-254-3 54-4 54-5 54-6 54-7 54-8 54-9 54-10 54-11 Data Data Data Data DataData Data Data Data Data Data Bond Record Record Record Record RecordRecord Record Record Record Record Record Number DR-1 DR-2 DR-3 DR-4DR-5 DR-6 DR-7 DR-8 DR-9 DR-10 DR-11 Bond 1 Deleted Deleted Deleted77.54 Deleted Deleted Deleted Deleted 81.90 Deleted Deleted

Table III-1 shows the results of performance of block 215 using TableI-1 and Table II-1. In this performance, X was set to provide a range ofplus four percent and minus six percent. Note that only data recordsDR-4 and DR-9 have survived the performance of block 215. Subsequentperformance of the remainder of method 200 now consumes fewer processingresources on server 58 with the deletion of the other data records.

A second test was run with a second bond referred to herein as Bond 2using method 200 b, the results of which are discussed below.

TABLE I-2 Exemplary Data Record DR-0 Block 208b of Method 200b EffectiveBond Issue CUSIP Maturity Maturity Traded Traded Traded Orig Prev/CDSNumber Name (Identifier) Coupon Date Date Date Amount Trades Price PricePrice Bond 2 Telus Corp. 87971MAH6 5.95 Apr. 15, Apr. 15, N/A N/A N/AN/A 99.53 99.53 2015 2015

Table I-2 shows an exemplary data record DR-0 that can be received atblock 208 b. The format of data record DR-0 in Table I-2 issubstantially the same as the format of Table I-1. Of note is that therehave been no prior trades, and there is no lead dealer, and thus as partof performance of method 300 analyzing data record DR-0, method 200 b isinvoked. Thus the bottom row in Table I-2 represents a singleperformance of method 200 b. Of note is that traded date, traded amount,trades, and traded price all indicate N/A, as no trades have beeneffected, and thus the value of 99.53 is extracted from the “Prev/CSPrice Field” for use at block 215 b.

TABLE II-2 Quoted Price Portion of Data Records for Bonds - Raw DataBlock 210b of Method 200b Server Server Server Server Server ServerServer Server Server Server Server 54-1 54-2 54-3 54-4 54-5 54-6 54-754-8 54-9 54-10 54-11 Data Data Data Data Data Data Data Data Data DataData Bond Record Record Record Record Record Record Record Record RecordRecord Record Number DR-1 DR-2 DR-3 DR-4 DR-5 DR-6 DR-7 DR-8 DR-9 DR-10DR-11 Bond 2 99.34 101.71 98.30 91.75 Not 95.93065 92.94 100.01 92.6599.54 97.36 submitted

Table II-2 shows the quoted price portion of data records DR-1 . . .DR-11 received from eleven quotation servers 54 (i.e. where n=11) aspart of performance of block 210. Thus each cell in Table II reflects aquoted price in the form of raw data as discussed above in relation toblock 210. The data has already undergone any relevant assessment andcorrection operations discussed above. Note that not all servers 54 needactually submit a data record DR for every bond issue, and hence nothinghas been received from server 54-5.

TABLE III-2 Data Records Surviving Deletion Block 215b Server ServerServer Server Server Server Server Server Server Server Server 54-1 54-254-3 54-4 54-5 54-6 54-7 54-8 54-9 54-10 54-11 Data Data Data Data DataData Data Data Data Data Data Bond Record Record Record Record RecordRecord Record Record Record Record Record Number DR-1 DR-2 DR-3 DR-4DR-5 DR-6 DR-7 DR-8 DR-9 DR-10 DR-11 Bond 2 99.34 101.71 98.30 DeletedNot 95.93 Deleted 100.01 Deleted 99.54 97.36 submitted

Table III-2 shows the results of performance of block 215 b using TableI-2 and Table II-2. In this performance X was set to plus or minus sixpercent. Note that only data records DR-1, DR-2, DR-3, DR-6, DR-8,DR-10, and DR-11 survived the performance of block 215 b. Subsequentperformance of the remainder of method 200 b now consumes fewerprocessing resources on server 58 with the deletion of the other datarecords DR.

TABLE IV-2 Data Records Surviving Deletion Block 225b Server ServerServer Server Server Server Server Server Server Server Server 54-1 54-254-3 54-4 54-5 54-6 54-7 54-8 54-9 54-10 54-11 Data Data Data Data DataData Data Data Data Data Data Bond Record Record Record Record RecordRecord Record Record Record Record Record Number DR-1 DR-2 DR-3 DR-4DR-5 DR-6 DR-7 DR-8 DR-9 DR-10 DR-11 Bond 2 99.34 101.71 98.30 DeletedNot 95.93 Deleted 100.01 Deleted 99.54 97.36 submitted

Table IV-2 shows the results of performance of block 225 b using TableIII-2. In this performance Y was set to two percent. Note that all ofthe data records from block 215 b survived the performance of block 225b, in that no records in this example were deleted as a result of block225 b.

TABLE V-2 Data Records Surviving Deletion Block 235b Server ServerServer Server Server Server Server Server Server Server Server 54-1 54-254-3 54-4 54-5 54-6 54-7 54-8 54-9 54-10 54-11 Data Data Data Data DataData Data Data Data Data Data Bond Record Record Record Record RecordRecord Record Record Record Record Record Number DR-1 DR-2 DR-3 DR-4DR-5 DR-6 DR-7 DR-8 DR-9 DR-10 DR-11 Bond 2 99.34 Deleted 98.30 DeletedNot Deleted Deleted Deleted Deleted 99.54 Deleted submitted

Table V-2 shows the results of performance of block 235 b using TableIV-2. In this performance Z was set to one. Note that only data recordsDR-1, DR-3 and DR-10 survived the performance of block 235 b.

TABLE VI-2 Final Price Determination-Data Record DRn + 1 Block 245bFinal Bid Price Final Price Yield Yield Mean Count Ask Bid Ask Bond 299.060112 3.00 99.795623 6.127557 5.988268

Table VI-2 shows the results of performance of block 245 b using TableV-2, to create data record DRn+1. “Final Bid Price Mean” reflects thefinal price calculation as discussed above in relation to block 245which is also applicable to block 245 b. This column entry alonesatisfies performance of block 245, however the other columns in TableVI-2 can also be provided as part of bock 255.

Final Count in Table VI-2 reflects the number of data records upon whichthe determination of final price was made—in this case, data recordsDR-1, DR-3 and DR-10.

Price Ask in Table VI-2 reflects a determined price that purchasers arecurrently paying for the particular bond. Price Ask can be determinedusing method 400 shown in FIG. 10. Method 400 can be performed inconjunction with method 200 (or its variants method 200 a and method 200b). Block 405 comprises receiving a bid-and-ask price spread from eachquotation engine 54. Each bid-and-ask price spread corresponds with thebond that is part of the quote received at block 210 (or its variants).The bid-and-ask price spread is the difference between the bid-price andthe ask-price of the relevant bond. The bid-price refers to the bidprice (i.e. the price that would be paid by the provider of the quote inpurchasing the relevant bond) that the particular dealer maintained onquotation server 54 in relation to the relevant bond. The ask-pricerefers to the asking price (i.e. the price that would be paid to theprovider of the quote in selling the relevant bond) that the particulardealer maintained on quotation server 54 in relation to the relevantbond. The bid-and-ask price can be received as part of performing block210 (or its variants).

Block 410 comprises determining the mean of the bid-ask-price spreadfrom the data records that survived deletion from block 235 (or itsvariants).

Block 415 comprises applying the results of block 410 to the Final BidPrice Mean from block 245. Applying can involved adding the mean of thebid-ask-price spread determined at block 410 to the Final Bid Price Meanfrom block 245.

Yield Bid reflects the determined rate of return for the particular bondwhen purchased at the bid price (indicated in the Final Price Bid Meancolumn of Table VI-2). Yield Ask Reflects the determined rate of returnfor the particular bond when purchased at the ask price (indicated inthe Price Ask column of Table VI-2).

The values of Final Price Bid Mean, Price Ask, Yield Bid and Yield Askabove are calculated in conjunction with a terms and conditions databasecontaining information for each active bond issue. The informationcontained in the terms and conditions database may include CUSIP, couponrates, first payment dates, issue dates, amortizing and prepaymentschedules, penalty payments, call dates, ratings, industry assignmentsand the like.

The foregoing examples are non-exhaustive of possible performances ofmethods 200, 200 a and 200 b but are intended to be illustrative.

The present invention provides a novel system and method for poolingcomputing resources in that: processing resources on engine 58 are usedmore efficiently as certain data records are at least ignored,processing resources on servers 54 are more efficiently used as servers54 can focus on other processing tasks while quotation determination isperformed on engine 58 rather than using each server 54 to analyzequotation data from all other servers 54; where records are completelydeleted from volatile or non-volatile storage or both during performanceof method 200 then the storage resources on engine 58 are moreefficiently utilized; storage resources of servers 54 are moreefficiently utilized as each server need not maintain copies ofquotations from each other server 54. Additionally, the systems andmethods provided herein allow for more efficient use of computingresources on servers 54 and quotation engine 58 due to the increasedaccuracy and reliability of the determined pricing, which in turn doesnot require additional verification or recalculation.

While the foregoing has focused on bonds, it will be understood thatother negotiable instruments (e.g. stocks, futures, commodities) arealso intended to be within the scope of the invention. The scope of thepresent invention is not intended to be restricted by the foregoing butis instead defined by the claims attached hereto.

1. A system for pooling computing server resources comprising: aplurality of quotation servers; each of said quotation serversconfigured to maintain a dealer data record comprising a quotation for abond; at least one of said dealer data records different than anothersaid dealer data record; a clearing server configured to maintain aclearing data record comprising an actual traded value for said bond; aquotation engine connected to said quotation servers and said clearingserver; said quotation engine configured to receive said dealer datarecords and said clearing data record; said quotation engine configuredto perform a plurality of operations based on said dealer data records;said operations configured to successively delete one or more of saiddealer data records; said operations based on a comparison of saidactual traded value with said quotations or a lead dealer quotation witha remainder of said quotations, wherein at least one of said pluralityof operations is configured to delete said dealer data records havingquotations greater than a predefined upper threshold or smaller than apredefined lower threshold and wherein said predefined upper and lowerthresholds are determined from one of said actual traded value and alead dealer quotation; said quotation engine configured to perform afinal price determination based on said surviving dealer data records.2. The system of claim 1, wherein said predefined upper threshold isbetween about 4% and about 25% higher than said one of said actualtraded value and said lead dealer quotation.
 3. The system of claim 1,wherein said predefined lower threshold is between about 4% and about25% lower than said one of said actual traded value and said lead dealerquotation.
 4. The system of claim 1, wherein said quotation engine isconfigured to perform said plurality of operations substantiallyimmediately after receiving said clearing data record.
 5. The system ofclaim 1, wherein said quotation engine is configured to perform saidplurality of operations about minutes after receiving said clearing datarecord.
 6. The system of claim 1, wherein said quotation engine isconfigured to perform said plurality of operations before an expiry ofsaid actual traded value.
 7. The system of claim 6, wherein said expiryof said actual traded value is the beginning of a subsequent tradingperiod.
 8. The system of claim 1, wherein the quotation engine isfurther configured to transmit a result of said final pricedetermination to at least one of said plurality of quotation servers. 9.The system of claim 8, wherein said quotation engine is furtherconfigured to transmit said result of said final price determination toones of said plurality of quotation servers associated with saidsurviving dealer data records.
 10. The system of claim 1 wherein saidactual traded value is from said clearing data record from a previoustrading period.